home *** CD-ROM | disk | FTP | other *** search
/ HPAVC / HPAVC CD-ROM.iso / pc / DDPLUS71.ZIP / LOCKING.ZIP / LOCKING.DOC < prev    next >
Encoding:
Text File  |  1995-03-16  |  8.8 KB  |  161 lines
  1.                        A FILE AND RECORD LOCKING UNIT
  2.                               Copyright 1995
  3.                                    By
  4.                       Michael Tischer and Bob Dalton
  5.  
  6.                                INTRODUCTION:
  7.                                ------------
  8.           What makes a door multi-node or on-line multi-user capable?
  9.           The answer is the use of file, and more importantly, record
  10.           locking to share data files between multiple copies of the
  11.           same program running in memeory. This unit adds those functions
  12.           to the DDPlus package. The NETFILEP.PAS code included in this
  13.           archive is FREEWARE and can be used in any manner you want and
  14.           without cost, but remains copyrighted to Michael Tischer.
  15.           Everything else is copyrighted by Bob Dalton. I have made
  16.           several changes to that unit to allow them to function better
  17.           with DDPlus, so blame any errors from changes on Bob Dalton.
  18.           I do not profess to be an expert on this topic, but not much
  19.           help seems to be available about this topic so I have decided
  20.           to take a swing at it.  Feel free to send me further information
  21.           or possible additions and/or corrections to this document.
  22.  
  23.                                 REQUIREMENTS:
  24.                                 ------------
  25.           At this point in time the only requirements are that you must
  26.           be using Borland Turbo Pascal version 6.0 or 7.0.  I compiled
  27.           the unit with Borland Pascal 7.0 Professional and know it
  28.           works. I expect it will with TP 6.0 as well but can't guarantee
  29.           it.  Be sure to have already compiled the DDPLUS.PAS unit BEFORE
  30.           compiling this one.  Also when used in your programs you must
  31.           warn the sysop that he/she MUST have DOS Share loaded.
  32.  
  33.                                 Files Included
  34.                                 --------------
  35.           Below is a listing of all files for the LOCKING.ZIP Package:
  36.           
  37.           GAME.CTL     - Required Configuration file for the LDEMO.EXE
  38.                           Program
  39.           LOCKING.DOC  - The text file you are reading.
  40.           LDEMO.EXE    - Compiled version of the LDEMO.pas program. So you
  41.                          see it in action immediately and see how file and
  42.                          record locking work. Not fancy, but it does the
  43.                          job!
  44.           LDEMO.PAS    - Source code to the Ldemo.exe program. 
  45.           NETFILEP.PAS - The locking routines unit by Michael Tischer.
  46.  
  47.                     Installation and Preparation for Use
  48.                     ------------------------------------
  49.  
  50.          1. Move the archive package to a temporary directory and "unzip".
  51.  
  52.          2. Try the LDemo.exe program first to see the end product BEFORE
  53.             looking at the code in the provided units. It will give you a
  54.             better feel for what is going on. Note: It's a door program so
  55.             be sure to use the /L parameter. Example:
  56.               
  57.                    LDEMO.EXE /L
  58.          
  59.          3. Before compiling the NETFILEP.pas unit be sure that your
  60.             compiler knows where to find the listed units.
  61.  
  62.          4. Add NETFILEP to the "Uses" portion of your program and call
  63.             the procedures as needed and shown below.
  64.  
  65.          5.  That's it!  Enjoy and good luck.
  66.  
  67.                           ABOUT FILE MODES
  68.                           ----------------
  69.      I recommend that you use only two filemodes: 64 (read)
  70.      or 66 (read write), because I have found them to work
  71.      the best and are the ones most trouble free.  Here's a
  72.      map of valid values for FileMode:
  73.  
  74.                                     ----- Sharing Method -----
  75.      Access         Compatibility   Deny   Deny    Deny   Deny
  76.      Method            Mode         Both   Write   Read   None
  77.      ---------------------------------------------------------
  78.      Read Only           0           16     32      48     64
  79.      Write Only          1           17     33      49     65
  80.      Read/Write          2*          18     34      50     66
  81.  
  82.      * = default
  83.  
  84.      FILE LOCKING VS RECORD LOCKING:
  85.      -------------------------------
  86.      File locking may be used for typed and text files.
  87.      I have found file locking to be most appropriate if there is
  88.      only ONE record in the file or it is a text file.  In the case
  89.      of non-text typed files I would suggest that you consider file
  90.      locking be used whenever you are going to overwrite the
  91.      ENTIRE file and not just a portion of it.
  92.  
  93.      Record locking may only be used for typed files and NOT text
  94.      files. Record locking is most useful when you only need to change
  95.      1 or more records in a file that contain many of them. A data
  96.      base file is a good example of this.  Record locking allows others
  97.      to access non-locked records.  File locking does NOT allow this, as
  98.      it is ALL or nothing. 
  99.      
  100.      To use record locking you must use the reset command first. Re-write
  101.      is NOT used with the record locking commands.  In multi-node and
  102.      on-line multi-player games I recommend that you use the locking
  103.      and unlocking routines in some type of loop to allow for the fact
  104.      that others might be trying to access that same record.  Without
  105.      a loop it will fail and generate an error otherwise.  Another
  106.      recommendation is to disable I/O checking to prevent unwanted error
  107.      reporting and system slow downs.
  108.  
  109.      One other thing I learned the hard way about record locking. To read
  110.      or write a record you must know the record number.  In your record
  111.      information assign a variable at the top of the list where you will
  112.      store a record number. These always begin at 0.  See my LDEMO.PAS
  113.      program for an example of this.  You can always search the record
  114.      based on an of the list variables you have. Good example would be
  115.      to find a player by the name of "BOB DALTON". Search on that name
  116.      until you find it and then you automatically know the record number
  117.      because it will have it's own variable. Again I know this may be
  118.      confusing and hopefully the example LDEMO.PAS program will make it
  119.      more clearer.
  120.  
  121.  
  122.                    STRATEGIES FOR ON-LINE MULTI-USER DOORS     
  123.                    ---------------------------------------
  124.      The main problems on the best way to update records and keep
  125.      information current seems to lie primarily with games, but can
  126.      also apply to any door where several people have access to records
  127.      at more or less the same time.  Game maps are a good example of
  128.      this.  If you are using a map in your game I would suggest you
  129.      consider each movement space on the map as a separate record in
  130.      a map database.  Doing it this way makes it easy to update and
  131.      prevent access problems and wrong information. When a player LEAVES
  132.      his current position on the map a procedure should be called to
  133.      update that map position record in the map database. Conversly
  134.      when a player enters a new map position you need to call a
  135.      procedure to read the map record for that position from the map
  136.      database file. It may not be the best method, but it works.
  137.      The downside to this is a lot of disk accessing always going on.
  138.      Whenever information changes on a door user you should consider
  139.      re-writing the users database file record. Not doing this means
  140.      that if another player accesses information on that user, it will
  141.      be old information and not correct.  I know this can be confusing,
  142.      but writing an on-line multi-player game is NOT easy for the novice
  143.      as there are many issues to be addressed.  In my door games I
  144.      have set up a looping procedure that constantly writes the players
  145.      current information to his database record and then immediately
  146.      reads that same record again to check for changes inflicted on the
  147.      player by other on-line players.  Again maybe not the BEST method,
  148.      but it works. Just remember that when you write the current users
  149.      information to his record that it is being OVERWRITTEN completely
  150.      by the new information. Conversely when you read that record it
  151.      is completely overwriting that record information in MEMORY for
  152.      that user.  Just food for thought....
  153.  
  154.                            THE LDEMO.PAS PROGRAM
  155.                            ---------------------
  156.      Also included in this package is LDEMO.EXE which is a sample door
  157.      program that demonstrates file and record locking much easier then
  158.      I can explain it to you.  The LDEMO.PAS file is the commented source
  159.      code that's shows you how everything was done.
  160.  
  161.